Структурный анализ с помощью диаграмм сущность-связь

2.4 Структурный анализ с помощью диаграмм сущность-связь

Широкое распространение реляционных СУБД и их использование в самых разнообразных приложениях показывает, что реляционная модель данных достаточна для моделирования предметных областей. Однако проектирование реляционной базы данных в терминах отношений на основе кратко рассмотренного нами механизма нормализации часто представляет собой очень сложный и неудобный для проектировщика процесс. При этом проявляется ограниченность реляционной модели данных в следующих аспектах:

1). Модель не предоставляет достаточных средств для представления смысла данных. Семантика реальной предметной области должна независимым от модели способом представляться в голове проектировщика. В частности, это относится к упоминавшейся нами проблеме представления ограничений целостности.

2). Для многих приложений трудно моделировать предметную область на основе плоских таблиц. В ряде случаев на самой начальной стадии проектирования проектировщику приходится производить насилие над собой, чтобы описать предметную область в виде одной (возможно, даже ненормализованной) таблицы.

3). Хотя весь процесс проектирования происходит на основе учета зависимостей, реляционная модель не предоставляет каких-либо средств для представления этих зависимостей.

4). Несмотря на то, что процесс проектирования начинается с выделения некоторых существенных для приложения объектов предметной области ("сущностей") и выявления связей между этими сущностями, реляционная модель данных не предлагает какого-либо аппарата для разделения сущностей и связей.

Далее мы кратко рассмотрим некоторые черты одной из наиболее популярных семантических моделей данных - модель "Сущность-Связи" (часто ее называют кратко ER-моделью).

На использовании разновидностей ER-модели основано большинство современных подходов к проектированию баз данных (главным образом, реляционных). Модель была предложена Ченом (Chen) в 1976 г. Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов. Основными понятиями ER-модели являются сущность, связь и атрибут. Сущность - это реальный или представляемый объект, информация о котором должна сохраняться и быть доступна. В диаграммах ER-модели сущность представляется в виде прямоугольника, содержащего имя сущности. При этом имя сущности - это имя типа, а не некоторого конкретного экземпляра этого типа. Для большей выразительности и лучшего понимания имя сущности может сопровождаться примерами конкретных объектов этого типа.

Нормальные формы ER-схем

Как и в реляционных схемах баз данных, в ER-схемах вводится понятие нормальных форм, причем их смысл очень близко соответствует смыслу реляционных нормальных форм. Заметим, что формулировки нормальных форм ER-схем делают более понятным смысл нормализации реляционных схем. Мы приведем только очень краткие и неформальные определения трех первых нормальных форм.

В первой нормальной форме ER-схемы устраняются повторяющиеся атрибуты или группы атрибутов, т.е. производится выявление неявных сущностей, "замаскированных" под атрибуты.

Во второй нормальной форме устраняются атрибуты, зависящие только от части уникального идентификатора. Эта часть уникального идентификатора определяет отдельную сущность.

В третьей нормальной форме устраняются атрибуты, зависящие от атрибутов, не входящих в уникальный идентификатор. Эти атрибуты являются основой отдельной сущности.

Диаграмма представлена в Приложении 2.

3. СОЗДАНИЕ ПРИЛОЖЕНИЯ В DELPHI

 

3.1 Работа с утилитой BDE Administrator

 

Назначение BDE Administrator

В Delphi для доступа к базам данных из приложения, как известно использует-ся цепочка "Приложение -> BDE -> База данных". Это означает что при любом обра-щении к БД из приложения реально адресуется BDE (напомним, это аббревиатура Borland Database Engine, машины баз данных фирмы Borland). BDE, используя соб-ственные функции, связывав непосредственно с базой данных. Действия, осуществля-емые при этом ВDE мы здесь обсуждать не будем, поскольку эта тема отдельного рассмотрения.

Для работы с конкретной базой данных BDE, во-первых, должна знать:

• где БД физически расположена;

• параметры этой БД;

• общие параметры драйвера БД того типа, к которому принадлежит. обрабатываемая БД;

• общие системные установки.

Параметры драйвера БД определяют параметры конкретной БД, знача которых не указаны.

Системные установки являются общими для всех драйверов.

Замечание. Те, кто работал с Delphi версий 1 и 2, будут поначалу неприятно удивлены, не обнаружив в 3-ей версии BDE Configuration Utility. Именно её функции и выполняет в Delphi 3 утилита BDE Administrator. Несомненно, что вы найдете в ней много общего с BDE Configuration Utility.

Создание псевдонима БД

Параметры БД и ее местоположение определяются псевдонимом БД. Псевдоним - это некоторое имя (псевдоним БД). Именно этот псевдоним и используют при логическом обращении к БД компоненты типа “набор данных” приложения Delphi, например ТТаble и TQuery. BDE считывает параметры поставленные в соответствие данному псевдониму, что во многом определяет ее дальнейшие действия по физической работе с БД.

Псевдонимы баз данных определяются в утилите BDE Administrator. Для того, чтобы определить псевдоним, необходимо:

1. Выбрать элемент меню Object \ New;

2. Выбрать в появившемся окне имя драйвера базы данных (STANDARD для Paradox и dBase, MSACCESS для Microsoft Access, ORAC INTRBASE, SYBASE, MSSQL, INFORMIX, DB2 соответственно для данных Oracle, InterBase, Sybase, MS SQL Server, Informix, DB2 и, если установлен, драйвер ODBC);

3. Ввести имя псевдонима в левом окне;

4. Определить необходимые параметры псевдонима в правом окне

5. Щелкнуть по псевдониму правой кнопкой мыши и выбрать всплывающем меню элемент Apply для подтверждения или Cancel отказа.

 

3.2 Создание таблиц базы данных

 

Объявление полей

Для создания таблиц базы данных необходимо запустить утилиту Database Desktop(DBD). После запуска утилиты установим рабочий псевдоним утилиты. Это псевдоним, с которым утилита работает по умолчанию. Если рабочий псевдоним не установлен, придется при работе с DBD всякий раз указывать псевдоним, что отнимает время.

Для установки рабочего псевдонима нужно выбрать элемент главного меню File| Working Directory и в выпадающем списке Aliases выбрать имя псевдоним РRОВА, после чего нажать кнопку ОK.

Для создания таблицы БД нужно выбрать элемент главного меню File| New| Table. В появившемся окне Create Table оставляем без изменения тип создаваемой таблицы (Paradox 7) и нажимаем кнопку Ok . После этого появится окно определения структуры таблицы БД.

Каждая строка таблицы соответствует полю. Назначения столбцов:

Fields Name -имя поля;

Туре - тип поля;

Size - размер поля (для строковых полей, поскольку иные поля подразумевают размер, определяемый типом поля);

Кеу - содержит звездочку '*', если поле входит в состав первичного ключа. Если в первичный ключ входит несколько полей, они должны определяться в той последовательности, в которой они присутствуют в первичном ключе. Кроме того, все поля, входящие в состав первичного индекса, должны определяться перед иными полями, то есть быть в списке полей наверху.

Определим поля, входящие в таблицу "Товары". Введем Тоvаrу в столбец field Name. Для того, чтобы определить тип поля, щелкните по столбцу

Туре и нажмите клавишу пробела. В ответ на это будет выдан список типов полей, из которых необходимо произвести выбор нужного типа.

Таблица 1 Лекарства

Номер	Название полей	Тип поля	Ключ
1	Код лекарства	N	*
2	Название лекарства	A
3	Срок годности	D
4	Упаковка	A
5	Вес	N

В таблице 1 поля имеют тип:

Код лекарства (N) имеет числовой тип, Название лекарства (А) символьные значения, Срок годности (D) дата, Упаковка (А) символьные значения, Вес (N) числовой тип .

Поле Код лекарства является ключевым(*).

Таблица 2 Предприятие:

Номер	Название полей	Тип поля	Ключ
1	Код предприятия	N	*
2	Название предприятия	A
3	Адрес предприятия	А

В таблице 2 поля имеют тип:

Код предприятия (N) имеет числовой тип, Название предприятия (А) символьные значения, Адрес предприятия (А)

Поле Код предприятия является ключевым(*).

Таблица 3 Накладная:

Номер	Название полей	Тип поля	Ключ
1	Номер накладной	N	*
2	Код предприятия	N
3	Дата накладной	D

В таблице 3 поля имеют тип:

Номер накладной (N) имеет числовой тип, Код предприятия (N)

числовой тип,

Дата накладной (D) дата.

Поле Номер Накладной является ключевым(*).

Таблица 4 Поступление:

Номер	Название полей	Тип поля	Ключ
1	Номер накладной	N
2	Код предприятия	N
3	Код лекарства	N
4	Код поступления	N	*
5	Цена за ед. лекарства	N
6	Кол-во лекарства	N

В таблице 4 поля имеют тип:

Номер накладной (N) числовой тип, Код предприятия (N) имеет числовой тип, Код лекарства (N) имеет числовой тип, Код поступления (N) имеет числовой тип, Цена за ед. лекарства (N) имеет числовой тип, Кол-во лекарства (N) имеет числовой тип.

Поле Код поступления является ключевым(*).

Таблица 5 Продажа:

Номер	Название полей	Тип поля	Ключ
1	Код лекарства	N
2	Номер чека	N	*
3	Дата продажи	D
4	Цена за ед. продукта	N
5	Кол-во проданных лекарств	N

В таблице 5 поля имеют тип:

Код лекарства (N) имеет числовой тип, Номер чека (N) имеет числовой тип, Дата продажи (D) дата, Цена за ед. продукта (N) имеет числовой тип, Кол-во проданных лекарств (N) числовой тип.

Поле Номер чека является ключевым(*).

Связи в базе организованны по соотношению один ко многим.

Для установления связей между таблицами открывали дочернюю таблицу

И выбирали в спадающем списке Table properties пункт Referential Integrity.

Связь таблицы Предприятие с таблицей Накладная.

Связь таблицы Лекарства с таблицей Продажа.

Связь таблицы Лекарства с таблицей Поступление.

По такому же принципу сделана связи с таблицей Накладная Поступление.