Диго С.М. Базы данных проектирование и использование (1084447), страница 25
Текст из файла (страница 25)
Если же отображаемая сущность не стабильна, то ее лучше передавать посредством данных, так как в противном случае будет часто требоваться преобразование программы, что обычно обеспечить труднее, чем изменение данных.
При отображении обобщенных объектов в БД возможны разные варианты: хранить информацию обо всем обобщенном объекте в одном файле/таблице, каждому подклассу объектов низшего уровня выделять отдельные самостоятельные файлы/таблицы. Оба эти варианта могут быть использованы в любой СУБД. В первом случае подчеркивается общность объектов разных подклассов, входящих в обобщенный объект. Во втором случае,
напротив, обобщенный объект как единое целое не отображается в структуре базы данных.
Другие способы отображения связаны с явным или неявным выделением подклассов в логической структуре БД. Неявное выделение подкласса заключается в том, что в записи отводятся поля для фиксации значений свойств, общих для объектов разных подклассов, и значения признака подкласса, а вместо полей, наличие которых зависит от подкласса, используется одно поле с переменным составом, содержание которого будет зависеть от того, к какому подклассу относится описываемый объект.
Реализация принципа явного выделения подклассов в структуре БД существенно зависит от специфики СУБД.
При проектировании логической структуры БД основное значение имеет специфика отображаемой предметной области. Однако, как отмечалось выше, и характер обработки информации оказывает влияние на принимаемое проектное решение. Например, рекомендуется хранить вместе информацию, часто обрабатываемую совместно, и, наоборот, разделять по разным файлам информацию, не использующуюся одновременно. Информацию, используемую часто, и информацию, частота обращения к которой мала, также следует хранить в разных файлах, причем последнюю может оказаться выгодным вынести в архивные файлы, а не поддерживать в составе БД.
Как отмечалось выше, в ИЛМ описывается не отдельный объект, а класс объектов. Но в редких случаях бывает, что класс включает в себя только один экземпляр объекта. Например, если предметной областью является какой-то конкретный институт, то класс объектов ИНСТИТУТ будет содержать только один экземпляр объекта. Таким «вырожденным» классам объектов обычно не ставится в соответствие отдельный файл базы данных.
3.1.4. Определение состава базы данных
При переходе от инфологической модели к даталогической следует иметь в виду, что инфологическая модель включает в себя всю информацию о предметной области, необходимую и достаточную для проектирования БД. Это не означает, что все сущности, зафиксированные в ИЛМ, должны в явном виде отражаться в даталогической модели. Прежде чем строить даталогическую модель, необходимо решить, какая информация будет храниться в базе данных. Например, в инфологической модели должны быть отражены вычисляемые показатели, но вовсе не обязательно, что они должны храниться в базе данных.
Существуют разные подходы к определению состава показателей, которые должны храниться в базе данных. Согласно одному из них в БД должны храниться только исходные показатели, все производные показатели должны быть получены расчетным путем в момент реализации запроса (этот подход иногда называют принципом синтезирования, имея в виду возможность синтезировать требуемые показатели из хранимых в информационной базе данных).
Такой подход имеет очевидные достоинства:
1) простота и однозначность в принятии решения «что хранить»;
2)отсутствие неявного дублирования информации со всеми вытекающими из этого последствиями (меньше объем памяти, чем при хранении как исходных, так и производных показателей; проще проблемы контроля целостности данных);
3) потенциальная возможность получить любой расчетный показатель, а не только те, которые хранятся в БД.
При принятии решения о хранении расчетных показателей должны учитываться разные факторы.
Рассмотрим некоторую гипотетическую предметную область, представляющую собой учебное заведение. Учащимся этого заведения начисляется стипендия. Существует четкий алгоритм начисления стипендии. Предположим, что он выглядит следующим образом.
1. Стипендия начисляется только тем, кто успешно сдал все экзамены в сессию (т.е. сдал в срок и не получал неудовлетворительных оценок), а также учащимся, имеющим детей.
2. Известен размер обычной стипендии.
3. Тем, кто не имеет удовлетворительных оценок, назначается стипендия на 25% выше, чем обычная.
4. Тем, кто имеет только отличные оценки, стипендия увеличивается на 50% от размера обычной стипендии.
Предположим также, что размер стипендии не может изменяться в течение семестра. Таким образом, размер стипендии является вычисляемым показателем и может не храниться в базе данных, а каждый раз определяться расчетным путем. Однако в рассматриваемой ситуации его все-таки лучше хранить в БД по следующим основным причинам:
а) полученная величина многократно используется в дальнейшем;
б) алгоритм определения размера стипендии имеет достаточно сложную логику, и для выполнения расчета требуется просмотреть несколько файлов (некоторые из них являются большими по объему, что также замедляет процесс обработки);
в) размер стипендии не должен изменяться в течение семестра. Кроме того, имея реальный файл «Начисленная стипендия», легче контролировать его полноту и достоверность.
Предположим также, что к БД достаточно часто обращаются с запросом о среднем балле какого-либо студента или среднем балле по той или иной дисциплине и т.п.
При изменении любой оценки или получении новой средний балл меняется, и если вы вдруг решите хранить и среднюю величину, и исходные оценки, то обеспечение их соответствия может стать проблемой. При правильной организации файлов вычисление средней величины во время исполнения запроса не представляет проблемы ни с точки зрения времени обработки, ни в аспекте задания запроса. Поэтому хранить средний балл не следует.
3.1.5. Введение искусственных идентификаторов
При отображении объекта в файл базы данных идентификатор объекта будет являться полем этого файла, причем в большинстве случаев - ключевым полем, т.е. полем, однозначно идентифицирующим запись. Однако в некоторых случаях появляется необходимость введения искусственных идентификаторов, или, как их еще называют, кодов. Такими случаями являются следующие.
1. В предметной области может наблюдаться синонимия, т.е. может случиться, что естественный идентификатор объекта не обладает свойством уникальности. Например, среди сотрудников предприятия могут быть однофамильцы. В этом случае для обеспечения однозначной идентификации объектов предметной области в информационной системе целесообразно использовать искусственные коды.
2. Если объект участвует во многих связях/процессах, то для их отображения создается несколько файлов/таблиц, в каждом из которых повторяется идентификатор объекта. Для того чтобы не использовать во всех файлах длинный естественный идентификатор объекта, можно ввести и использовать более короткий код. Например, вместо длинных наименований продукции обычно используются их кодовые обозначения. Это не только сэкономит память, но и сократит трудоемкость ввода информации (хотя последнего можно достичь и другим путем).
3. Если естественный идентификатор может изменяться со временем (например, фамилия), то это может вызвать много проблем, если наряду с таким динамическим идентификатором не использовать статический искусственный идентификатор.
Когда присваиваются идентификаторы каким-либо объектам, то желательно, чтобы эти идентификаторы были постоянными. Например, в учебных заведениях всегда каким-либо образом обозначаются учебные группы. Для этого можно, например, использовать номер курса, на котором в настоящее время учится данная группа, и какие-то другие символы (подобно тому, как обозначаются классы в школе). Но в этом случае идентификатор группы будет каждый год меняться. А можно для обозначения группы использовать, например, две последние цифры года поступления. В этом случае идентификатор группы будет постоянным. Использование постоянных идентификаторов снимает множество проблем при функционировании информационной системы.
Встречаются и иные случаи, когда целесообразно вводить искусственные идентификаторы. Некоторые из них будут рассмотрены далее при обсуждении проблем проектирования БД.
3.1.6. Критерии оценки БД
Для оценки проектируемой/спроектированной БД может быть использовано множество критериев. Значимость этих критериев, в свою очередь, будет зависеть от большого числа разнообразных факторов. Прежде всего эта значимость зависит от самого критерия: есть критерии, значимость которых не только никогда не понижается, а, наоборот, постоянно растет (это такие критерии, как адекватное отображение действительности, удовлетворение разнообразных потребностей пользователей и т.п.). Значимость других критериев становится менее существенной с ростом возможностей техники и программного обеспечения (например, занимаемый базой данных объем памяти).
На значимость критерия оценки влияют особенности ИС, для которой создается проект (например, для систем, работающих в реальном масштабе времени, очень важна скорость реакции системы на запросы, для банковских систем - защита информации и надежность системы).
Все критерии оценки являются взаимосвязанными и часто противоречивыми: улучшение показателей по одному из критериев может привести к ухудшению значений показателей, оценивающих модель по другим критериям. Необходима комплексная оценка проекта по всей совокупности критериев, которые могут быть как количественными, так и качественными.
Перечислим основные критерии, используемые при оценке БД.
1. Адекватность - соответствие базы данных реальной предметной области. Естественно, что БД не должна искажать предметную область. Это является важнейшим требованием к БД, без соблюдения которого бессмысленно соблюдение всех остальных требований. Оценка адекватности является не только очень важной, но и очень трудной задачей, поскольку некоторые несоответствия трудно выявить. Адекватность должна быть обеспечена как на уровне структуры БД, так и при задании ограничений целостности. Так, например, если в предметной области могут быть однофамильцы, а вы зададите ФИО как ключ, то запись, касающаяся однофамильца, не сможет быть введена в базу данных.
2. Полнота - возможность удовлетворения существующих и новых потребностей пользователей. Использование подхода «от предметной области» к проектированию баз данных и сама идеология банков данных как интегрированного взаимоувязанного хранилища данных способствуют обеспечению этого критерия. Хранение в БД детализированных показателей также повышает возможности удовлетворения разнообразных (в том числе и нерегламентированных) потребностей пользователей. Полнота является одним из проявлений адекватности БД.
3. Адаптируемость.
3.1. Адаптируемость к изменениям в предметной области.
3.1.1. Устойчивость схемы базы данных - отсутствие необходимости в изменении структуры БД при изменении предметной области. В теории БнД широко используется понятие независимости программ от данных и данных от программ. Не менее, а даже более значимой является проблема обеспечения независимости логической модели БД от изменений, происходящих в предметной области. Устойчивость модели является лучшим проявлением свойства адаптируемости системы. Обеспечение устойчивости модели базы данных к изменениям предметной области фактически снимает проблему независимости программ от данных, так как в этом случае структуры данных меняться не будут.
Поясним суть данного показателя на примере. Предположим, необходимо хранить информацию об успеваемости студентов. Ниже приведены некоторые из возможных вариантов структуры БД для хранения этой информации. Вариант 1 предполагает, что создается таблица. В ее строках помещаются фамилии студентов, графами являются названия предметов, а значениями соответствующих полей будет оценка, полученная данным студентом по данному предмету. Каждому студенту соответствует одна запись в БД. Такой вариант очень похож на «Книги баллов», которые традиционно ведутся в деканатах. Для обсуждения проблемы устойчивости модели несущественно, а для оценки БД по другим критериям будет иметь значение, сколько таблиц создано (так как студенты учатся по разным учебным планам, то при создании только одной таблицы будет много пустых значений полей, содержащих оценки, а каждая запись будет содержать слишком большое число полей).
Вариант 1
| ФИО | Высш_мат. | Ин._яз. | БД | … |
| Иванов | 5 | 4 | 5 | … |
| Якушкина | 4 | 5 | 4 | … |
В варианте 2 таблица содержит только три поля: «ФИО», «Предмет», «Оценка». Для каждого студента будет создано столько записей, сколько экзаменов сдал этот студент.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
