Общие принципы разработки приложений баз данных в среде Delphi 3 (стр. 1 )

Часть 1

Общие принципы разработки приложений баз данных в среде Delphi 3

1. Введение в базы данных

1.1. Понятие баз данных. Степень детализации информации в базе данных

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

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

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

Организация А характеризуется невысоким ассортиментом хранимых и отпускаемых товаров. Ассортимент отличается стабильностью. Состав реальных покупателей товаров исчисляется несколькими лицами (только юридическими). Предоплаты за еще не отпущенный товар не допускаются, отпуск товара в кредит не практикуется, система скидок отсутствует. Оплата производится в рублях. Отпуск товаров осуществляется с одного склада. Потребности в автоматизации учета отпуска товаров определяются двумя целями:

• быстрой выдачей информации о текущих остатках товара на складе;

• ежемесячной выдачей отчета об общих суммарных отпусках товара.

Организация Охарактеризуется множеством территориально распределенных складов, в том числе в различных государствах ближнего зарубежья. Ассортимент отпускаемых товаров высок и быстроизменчив в силу изменчивости спроса. Состав покупателей крайне разнообразен, в число покупателей входят как физические, так и юридические лица. Практикуется система скидок постоянным покупателям и покупателям, приобретающим товар свыше определенного количества и (или) суммы. Развита система предоплат, отпуска товаров в кредит. Оплата производится в местной валюте по текущему курсу доллара, реже - рубля. Потребности в автоматизации учета отпуска товаров определяются широким диапазоном целей:

быстрым получением информации о текущих остатках товара, в том числе на конкретном складе; по регионам; по всей организации; получением отчета об общих суммарных отпусках товара за любой временной интервал в любой валюте, в том числе по всей организации;

по конкретному региону, где расположены склады; по конкретному складу; по конкретному покупателю - отдельно для физических и юридических лиц; по группам покупателей, объединенным по одному признаку - например, территориальному; зачетом предоплат и задолженностей отдельных покупателей; автоматическим переводом покупателей в льготные категории, имеющие право на тот или иной вид скидки;

• прогнозированием с определенным уровнем вероятности будущего спроса (по покупателю, товару, региону) и т. д. Ввиду различия целей внедрения БД и содержания деловых процессов в Организациях А и Б, созданные в этих организациях базы данных будут существенно отличаться друг от друга - прежде всего детализацией хранимой информации и, следовательно, структурой данных. Если для организации А в БД достаточно хранить сведения о приходе и расходе товаров и о ценах на них, то в БД организации Б необходимо хранить десятки таблиц и в процессе работы тратить дополнительные усилия (реализуемые как вручную, так и автоматически) для того, чтобы поддерживать их в согласованном состоянии.

1.2. Реляционные базы данных

Реляционные БД представляют связанную между собой совокупность таблиц баз данных (ТБД). Связь между таблицами может находить свое отражение в структуре данных, а может только подразумеваться, то есть присутствовать на неформализованном уровне.

Каждая таблица БД представляется как совокупность строк и столбцов, где строки соответствуют экземпляру объекта, конкретному событию или явлению, а столбцы - атрибутам (признакам, характеристикам, параметрам) объекта, События, явления.

На рис. 1.1. приведен пример таблицы БД, в которой содержатся сведения об отпуске товара со склада. Столбцы представляют собой такие параметры, как дата отпуска товара, наименование отпущенного товара, наименование покупателя, количество единиц отпущенного товара. Каждая строка содержит введения о конкретном событии отпуска товара покупателю. в терминологии теории реляционных БД таблицам соответствуют отношения, столбцам - атрибуты, строкам - кортежи.

При практической разработке БД таблицы так и зовутся таблицами, строки - записями, столбцы - полями или столбцами ТБД.

Дата	Товар	Покупатель	Отпущено, ед.
10.02.97	Сахар	Геракл, ТОО	100
10.02.97	Сахар	Геракл, ТОО	100
12.02.97	Сахар	Пищеторг, ЗАО	2000
12.02.97	Макароны	Пищеторг, ЗАО	300
14.02.97	Сахар	Геракл, ТОО	200
15.02.97	Дрожжи	База № 28	100

Рис 1 1 Таблица базы данных "Отпуск товаров со склада "

Предшественниками реляционных БД были иерархические и сетевые базы данных. В иерархических БД информация хранилась в виде иерархий. На рис. 1.2 приведен пример такой иерархии; из ее рассмотрения становится ясно, для того, чтобы получить элемент данных А 12, нужно сначала отыскать в БД узел А, спуститься к узлу А1 и затем - к узлу А 12.

Сетевая БД характерна внутренними ссылками между структурами данных. Если от элемента В имеется ссылка на элемент А, возможен выбор элемента данных А (рис. 1.3).

Реляционные БД в 70-х годах практически вытеснили БД других видов. В качестве основной причины этого называют сложность представления данных в иерархической и сетевой моделях и необходимость определения связей между данными на этапе проектирования БД, в то время как в реляционных БД связи между таблицами могут устанавливаться непосредственно в момент выполнения запросов. Кроме того, разработчикам и пользователям значительно проще отображать сущности предметной области в табличных структурах данных.

Однако иерархический и сетевой подходы продолжают жить, они находят свое воплощение в отдельных специализированных БД и являются

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

Реляционные БД имеют мощный теоретический фундамент, основанный на математической теории отношений. Он был разработан доктором Эдгаром Коддом. Для построения запросов к реляционным БД был также разработан язык SQL (Structured Query Language, язык структуризированных запросов). Он приобрел характер промышленного стандарта в реляционных системах управления базами данных (СУБД). Поэтому, переходя с одной реляционной базы на другую, пользователь и разработчик имеют дело с одним и тем же языком. Другим важным плюсом SQL является то, что этот язык ориентирован на высокоуровневые операции с данными. Выдавая запрос, можно не беспокоиться о низкоуровневых проблемах доступа к данным, специфичных для каждой БД, поскольку интерпретация запросов в команды низкого уровня лежит в ведении конкретной СУБД.

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

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

1.3. Понятие первичного ключа

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

На рис. 1.4 показана таблица "Сотрудники". В качестве первичного ключа не могут использоваться поля:

• ФИО - поскольку практически известно, что даже в одном отделе могут работать однофамильцы с одинаковыми инициалами или даже полные тезки;

• должность - поскольку хотя для данного примера названия должностей и уникальны, в любом отделе наверняка найдутся сотрудники, занимающие одну и ту же должность;

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

№ пропуска	ФИО	Должность	Отдел	Год рожд.
111222		нач. отдела	122	1940
333444		диспетчер	122	1942
234567		наладчик	118	1940
101010		кладовщик	118	1967
202020		инженер	196	1966

Рис. 1.4. Таблица "Сотрудники"

В качестве первичного ключа может выступать номер пропуска, но при этом нужно сделать оговорку. Если номер пропуска недавно уволившегося сотрудника не может быть назначен сотруднику, впоследствии принятому на работу (т. е. является уникальным во времени), нет никаких ограничений на использование этого поля в качестве первичного ключа. Если же номер пропуска уволившегося сотрудника может быть назначен вновь поступившему сотруднику, следует изучить вопрос - удаляется ли информация об уволившемся сотруднике из базы данных? Если да, то поле может быть первичным ключом; если нет - не может быть первичным ключом, поскольку в базе данных могут присутствовать два сотрудника с одинаковым номером пропуска. В этом случае следует добавить в таблицу семантически незначащее поле (то есть не имеющего иного смысла, кроме обеспечения уникальности записи), например числовое поле NN (рис. 1.5.).

№	№ продукта	ФИО	Должность	Отдел	Год рожд.
	111222		нач. отдела	122	1940
2	333444		диспетчер	122	1942
i4	234567		наладчик	118	1940
>2	101010		кладовщик	118	1967
21	202020		инженер	196	1966

Рис. 1.5. Таблица "Сотрудники" после введения уникального поля

Уникальность подобного поля обычно отслеживается или программно, или автоматически. В первом случае при добавлении нового сотрудника приложение, работающее с базой данных, отыскивает максимальный номер сотрудника, увеличивает на 1 и назначает вновь добавляемой записи. Во втором случае первичный ключ реализуется через автоинкрементное поле. Для него сказанные действия выполняются автоматически системой управления базой данных. Существуют и иные способы обеспечения уникальности значений ключевого числового поля, они зависят от особенностей конкретной СУБД.

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

счета, при условии, что в организации существуют деловые правила, согласно которым один и тот же номер не может быть назначен двум счетам или накладным.

Приведем другие примеры первичных ключей:

• номер и серия паспорта;

• номер двигателя;

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

• название факультета, кафедры, года приема - для именования учебных групп в вузах;

• номер лицевого счета в бухгалтерском балансе;

• дата - если событие может случиться в течение даты только единожды, например, поставка продуктов в заводскую столовую;

• дата и время отказа сетевого оборудования, а при наличии нескольких потенциально сбойных узлов - адрес (номер) узла (если сбой узла характеризуется несколькими типами ошибок - еще и номер ошибки);

• почтовый адрес организации - с указанием номеров комнат, в случае, если в одном здании располагается несколько организаций (например, офисное здание);

• банковские реквизиты;

• регистрационный номер банка, организации;

• дата, номер страхового полиса, специализация и (или) фамилия и инициалы врача-специалиста - при обращении в поликлинику и т. д.

Замечание. Может показаться, что банковские реквизиты не могут однозначно характеризовать организацию, поскольку одна организация может иметь несколько счетов в различных банках. Но реквизиты конкретного счета являются уникальными и, следовательно, могут однозначно характеризовать организацию; наименование же организации не может однозначно характеризовать реквизиты ее банковских счетов, которых может быть несколько. На практике, реквизиты счета вряд ли будут использованы в качестве первичного ключа, поскольку эти реквизиты громоздки; тем не менее, с теоретической точки зрения, такое возможно.

При детальном рассмотрении природы первичных ключей рано или поздно возникает вопрос: если в рамках данной предметной области мы можем обойтись без первичного ключа, стоит ли вводить искусственный первичный ключ? Например, пусть приведенная выше на рис. 1.1 таблица "Отпуск товаров со склада" используется только для подсчета суммарного отпуска товаров за временной период. Тогда однозначно характеризовать запись вроде бы ни к чему - записи используются только в группировках по датам. Однако в процессе отладки приложений, работающих с базами данных, при возникновении сбоев, потерь данных, нарушении смысловой целостности всегда нужно знать, с какой именно записью мы имеем дело. Роль уникального идентификатора записи в этом случае трудно переоценить. Поэтому не только правила хорошего тона при разработке структур баз данных, но и чисто практические соображения должны побудить разработчика всегда определять первичный ключ для таблицы базы данных.

1.4. Реляционные отношения (связи) между таблицами базы данных

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

Существует три разновидности связей между таблицами базы данных: "один-ко-многим", "один-к-одному", "многие-ко-многим".

1.4.1. Отношение "один-ко-многим"

Отношение "один-ко-многим" имеет место, когда одной записи родительской таблицы может соответствовать несколько записей в дочерней таблице.

Как видно из рис. 1.6, одной записи из родительской таблицы "Товары" может соответствовать несколько записей в дочерней таблице "Отпуск товаров". Обратите внимание на глагол может: он означает, что такая возможность - потенциальная и что в родительской таблице могут найтись записи, для которых в данный момент нет записей в дочерней таблице (например, товар "Куры").

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

Связь "один-ко-многим" иногда называют связью "многие-к-одному". В этом случае подразумевается, что мы смотрим со стороны дочерней таблицы

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

Связь "один-ко-многим" является самой распространенной для реляционных баз данных. Как можно заметить, она позволяет моделировать иерархии данных.

В широко распространенной нотации структуры баз данных IDEFIX отношение "один-ко-многим" изображается путем соединения таблиц линией, которая на стороне дочерней таблицы оканчивается кружком или иным символом. Поля, входящие в первичный ключ для данной ТБД, всегда расположены вверху и отчеркнуты от прочих полей линией (рис. 1.7).

1.4.2. Отношение "один-к-одному"

Отношение "один-к-одному" имеет место, когда одной записи в родительской таблице соответствует одна запись в дочерней таблице (рис. 1.8.).

Данное отношение встречается много реже, чем отношение "один-ко-многим". Его используют, если не хотят, чтобы таблица БД "распухала" от второстепенной информации. Использование связи "один-к-одному" приводит к тому, что для чтения связанной информации в нескольких таблицах приходится производить несколько операций чтения вместо одной, когда данные хранятся в одной таблице. Кроме того, базы данных, в состав которых входят таблицы со связью "один-к-одному", не могут считаться до конца нормализованными (о нормализации см. ниже).

Связь "один-к-одному" может быть жесткой и нежесткой. В первом случае для каждой записи в родительской таблице должна существовать запись в дочерней таблице. Во втором случае - запись в дочерней таблице может как существовать, так и отсутствовать.

1.4.3. Отношение "многие-ко-многим"

Отношение "многие-ко-многим" имеет место, когда:

а) записи в родительской таблице может соответствовать больше одной записи в дочерней таблице;

б) записи в дочерней таблице может соответствовать больше одной записи в родительской таблице.

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

Таблица "Учебные группы и Таблица "Преподаватели" дисциплины"

Группа	Предмет	№ преподавателя		№ преподавателя	ФИО преподавателя	Кафедра
ПС-1	Программирование	10	->	10		ТИ-1
ТИ-1	Программирование	12		12		ТИ-1
ПС-1	Теория систем	10		62		РИО
РТ-2	Философия	62		78		ТИ-1
ПС-1	Социология	62		85		ЭИ-1
...	...	...		...	...	...

Рис 1.9 Связь "многие-ко-многим"