Упрощенная база даних для обложения пациентов в больнице SQL

Платформа Автоматично Перекладає Описание на английском языке, Для Читабельного Формату Необходимо Вимкнути Автоматический Перевод Биля Назви Проєкту.Взрыв до Бази Даних Наведени Нижче.Сама Структура Та Описание Проекту Надани В Закріпленому Файле.Проект Мае Бути Виконаний на английском языке.Проект Не Включает В Себе Интерфейс Для Користувачів, Це Мае Бути Лише Код SQL.Приложение должно содержать слой базы данных и слой приложения, написанный в Pl/Sql, соответственно, в T-Sql.Цель состоит в том, чтобы не писать пользовательский интерфейс.Приложение будет содержать соответствующее количество взаимосвязанных таблиц.Подходящее число – 7-10 таблиц плюс/минс в зависимости от типа приложения.Решение должно включать: определение необходимых таблиц, в том числе определения первичных, кандидатов и иностранных ключей.Определение соответствующих индексов, в том числе тех, которые проходят через все иностранные ключи.Определение других ограничений целостности для обеспечения целостности ввода данных.Триггеры наблюдают за вещами, которые не могут быть контролированы на ограниченном уровне.Несуществующий пользовательский интерфейс должен быть симулирован видениями, соответствующими индивидуальным экранам.Э. ГИтак:Список клиентов, включая данные из (... до одного) связанных таблиц перечня кредитов, включая данные клиентов и заемные титулы.Список кредитов после срока.Список доступных книг для книжных заголовков и т.д.(в зависимости от приложения) отдельные таблицы (по крайней мере основные) должны определять пакеты процедур, функций и других необходимых объектов, которые манипулируют субъектами, как это обычно происходит в программировании объектов и представляют слой приложения.Процедуры и функции должны гарантировать, что вводные данные имеют смысл.Реф .Они должны быть осведомлены о том, что вызовы и ограничения могут отказаться от некоторых манипуляций и правильно поддерживать исключения.Пример методов для клиентов в библиотеке: добавление нового клиента.Удаление клиента (если ничего не затягивается) новая регистрация кредита.Возврат конкретного кредита.Возврат всех кредитов клиента.Расчет штрафов за превышение срока и т.д.(в зависимости от приложения) схема должна быть разумно индексирована так, чтобы запросы для всех данных просмотра не требуют более одного полного сканирования (на контрольной таблице).Скл заявления в процедурах и функциях не должны требовать полного сканирования, за исключением конкретных ситуаций, поскольку они справляются с ограниченным набором линий.Учитывайте параллельное выполнение множественных инстанций программы над общими данными.Критические секции программ должны надлежащим образом использовать возможности транзакций, в том числе стол-закрытие и Роу-закрытие для достижения консистенции данных.Решение должно включать, по крайней мере, следующие скрипты: создание всей схемы.Введение демо-данных, генерирующих статистику для всех таблиц схемы (в Oracle) выбросы статистики для всех таблиц схемы (в Oracle) правильное выбросы всего содержания схемы тест-скрипт, который демонстрирует функциональность всех предлагаемых публичных методов в процедурном интерфейсе и просмотр Функциональность.К примеру:
— Как выглядят все клиенты перед изменениями?Выберите * из View_On_Customers;
— добавить еще одного клиента в список клиентов...
Иск Db_Customer.New_Customer (...);
— Мы будем менять адрес...
Иск Db_Customer.Customer_Change (...);
—...Мы пытаемся удалить клиента с кредитами...
Иск Db_Customer.Delete_Customer (...);
... и кто-то без них
Иск Db_Customer.Delete_Customer (...);
— Как клиенты наблюдают за изменениями?Выберите * из View_On_Customers;
... не забудьте комментировать свои сценарии для каждого сценария, должно быть возможно распознать автора.В скрипте 1 ) задание должно быть описано.Скрипт 1) должен описывать значение отдельных объектов в схеме, включая табличные колонны и процедурные и функциональные параметры скрипт 6) должен описывать, что тестируется призывом, и особенно, что призыв должен закончиться ошибкой (что, почему).Для более сложных запросов и команд SQL, напишите, что они делают.Без комментариев, смысл приказа трудно найти.

Платформа автоматично перекладає опис англійською мовою, для читабельного формату потрібно вимкнути автоматичний переклад біля назви проєкту.

Вимоги до бази даних наведені нижче. Сама структура та опис проєкту надані в закріпленому файлі. 

Проєкт має бути виконаний англійською мовою. Проєкт не включає в себе інтерфес для користувачів, це має бути лише код SQL.

• The application should contain a database layer and an application layer written in PL/SQL, respectively in T-SQL. The goal is not to write a user interface.
• The application will contain a suitable number of interrelated tables. A suitable number is 7-10 tables plus/minus according to the application type. 
• The solution should include:
  • Definition of necessary tables, including definitions of primary, candidate and foreign keys.
  • Definition of suitable indexes including those through all foreign keys.
  • Definition of other integrity constraints to ensure the integrity of the data input.
  • Triggers monitoring things that can not be monitored at constraint level.
  • The non-existent user interface should be simulated by the views corresponding to the individual screens. E.g.:
    • List of customers including data from (... to one) associated tables
    • List of borrowings, including customer data and borrowed titles.
    • List of borrowings after the deadline.
    • List of available books for book titles
    • etc. (depending on the application)
  • Individual tables (at least the main ones) should have defined the packages of procedures, functions and other necessary objects that manipulate the entities as it is usual in object programming and represent the application layer. Procedures and functions should make sure that input data is meaningful. Resp. they should be aware of the fact that triggers and constraints can refuse some manipulations and maintain exceptions correctly. Example of methods for customers in the library:
    • Adding a new customer.
    • Customer deletion (if nothing is lent)
    • New borrowing registration.
    • Return of a specific loan.
    • Return of all customer loans.
    • Calculation of penalties for exceeding the deadline
    • etc. (depending on the application)
• The schema should be reasonably indexed so that queries for all view data do not require more than one FULL-SCAN (on the control table). SQL statements in procedures and functions should not require any FULL-SCAN except for specific situations because they handle a limited set of lines.
• Take into account the parallel execution of multiple instances of the program over shared data. Critical sections of programs should appropriately use transaction capabilities, including table locking and row locking to achieve data consistency.
• The solution should include at least the following scripts:
  1. Creation of the whole schema.
  2. Insertion of demo-data
  3. Generating statistics for all schema tables (in Oracle)
  4. Dropping statistics for all schema tables (in Oracle)
  5. Correct dropping of the whole schema content
  6. A test script that would demonstrate the functionality of all proposed public methods in the procedural interface and view functionality. For example:
     

     --how look all customers before the changes?
     
      select * from view_on_customers;
     
      --add another customer to the list of customers ...
     
      exec db_customer.new_customer(...);
     
      --... we will change the address ...
     
      exec db_customer.customer_change(...);
     
      --... we try to delete the customer with loans ...
     
      exec db_customer.delete_customer(...);
     
      -- ... and someone without them
     
      exec db_customer.delete_customer(...);
     
      --How do the customers look after changes?
     
      select * from view_on_customers;
     
      ...

• Don't forget to comment your scripts
  • For each script, it should be possible to recognize the author.
  • In script 1), the assignment should be described.
  • Script 1) should describe the meaning of individual objects in the schema, including table columns and procedural and function parameters
  • Script 6) should describe what is being tested by the call, and especially that the call should end up with an error (what, why).
  • For more complex SQL queries and commands, write what they are doing. Without comment, the meaning of the command is hard to find.