1. Взаимосвязь между оригинальным документом и организацией
Это могут быть отношения один к одному, один к многим и многие-в-многие. В целом, это отношения один к одному: то есть пара оригинальных документов
должно и только соответствовать одной сущности. В частных случаях это могут быть отношения один к многим или многие, то есть один оригинальный документ соответствует нескольким реальностям
тело или несколько оригинальных документов, соответствующих одной организации. Сущность здесь можно понимать как базовую таблицу. После уточнения этого соответствия, разработайте для нас
Интерфейс входа очень полезен.
〖Пример 1〗: Информация о резюме сотрудника соответствует трём базовым таблицам в системе информации о кадрах: таблице базовой информации сотрудника и обществу
Таблица отношений, форма резюме на работе. Это типичный пример «один оригинальный документ соответствует нескольким сущностям».
2. Первичные и внешние ключи
В целом, у организации не может быть ни первичный, ни внешний ключ. В диаграмме E-R сущности в листовой части могут определить первичный ключ,
Также возможно не определить первичный ключ (потому что у него нет потомков), но он должен иметь внешний ключ (потому что у него есть отец).
Проектирование первичных и внешних ключей занимает важное место в проектировании глобальных баз данных. После завершения проектирования глобальной базы данных возникает
Американские эксперты по проектированию баз данных сказали: «Ключи, ключи повсюду, только ключи», это его опыт в проектировании баз данных
Она также отражает его крайне абстрактные представления о основе информационных систем (моделей данных). Потому что: первичный ключ — это крайне абстрактная сущность, а первичный ключ ассоциируется с
Пара внешних ключей, представляющая связь между сущностями.
3. Природа базовой таблицы
Базовая таблица отличается от промежуточной и временной таблицы тем, что обладает следующими четырьмя характеристиками:
(1) Атомичность. Поля в базовой таблице больше не разлагаемы.
(2) Примитивность. Записи в базовой таблице — это записи исходных данных (базовых данных).
(3) Дедуктивно. Все выходные данные могут быть получены из базовой и кодовой таблицы.
(4) Стабильность. Структура базовой таблицы относительно стабильна, и записи в ней должны храниться долгое время.
После понимания природы базовых таблиц при проектировании баз данных их можно отличить от промежуточных и временных таблиц.
4. Стандарты парадигмы
Взаимосвязь между базовой таблицей и её полями должна максимально соответствовать третьей парадигме. Однако проекты баз данных, соответствующие третьей парадигме, часто не являются такими
Лучший дизайн. Для повышения операционной эффективности баз данных часто необходимо снизить стандарт парадигмы: соответствующим образом увеличить избыточность для достижения пространства во времени
Цель.
Пример 2: Существует базовая таблица хранения товаров, как показано в Таблице 1. Наличие поля «Сумма» указывает на то, что таблица не рассчитана на выполнение
Третья парадигма достаточна, поскольку «сумма» можно получить, умножив «единичную цену» на «количество», что указывает на то, что «сумма» является избыточным полем. Однако рост
Избыточное поле «величина» может повысить скорость статистики запросов — это практика обмена пространством на время.
В Rose 2002 существует два типа предписанных столбцов: столбцы данных и вычисленные столбцы. Столбец вроде «сумма» называется «столбцем расчёта», и
Столбцы, такие как «Цена единицы» и «Количество», называются «столбцами данных».
Таблица 1 Структура таблицы товаров
Название продукта Модель продукта Цена единицы Количество
ТВ 29 дюймов 2 500 40 100 000
5. Понимайте три парадигмы простыми словами
Понимание трёх парадигм простыми словами очень полезно для проектирования баз данных. В проектировании баз данных, чтобы лучше применить три парадигмы, просто
Три парадигмы следует понимать простым языком:
Первая парадигма: 1NF — это атомарное ограничение на атрибуты, которое требует, чтобы атрибуты были атомарными и больше не могут быть разложены;
Вторая парадигма: 2NF — это ограничение уникальности записей, требующее от записей уникальной идентификации, то есть уникальности сущности;
Парадигма 3: 3NF — это ограничение на избыточность полей, то есть ни одно поле не может быть получено из других полей, оно требует, чтобы оно не было избыточным
。
Никакое дублирующее проектирование баз данных не может этого сделать. Однако база данных без избыточности не обязательно является лучшей базой данных, иногда ради улучшения удачи
Для достижения эффективности необходимо снизить стандарт парадигмы и правильно сохранить избыточные данные. Конкретный подход заключается в соблюдении третьей парадигмы при проектировании концептуальных моделей данных
, работа по снижению стандарта парадигмы учитывается при проектировании модели физических данных. Снижение парадигмы — это добавление полей, позволяющих использовать избыточность.
6. Умейте хорошо выявлять и правильно управлять отношениями «многие-до-многие»
Если между двумя сущностями существует связь много-к-многим, эта связь следует устранить. Способ устранить это — добавить треть реала между ними
Тело. Таким образом, то, что раньше было отношениями «много к многим», теперь превратилось в два отношения «один к многим». Атрибуты двух исходных сущностей должны быть разумно распределены
Иди к трём сущностям. Третья сущность здесь по сути является более сложной связью, которая соответствует базовой таблице. В общем, цифры
Инструмент проектирования библиотек не может распознавать отношения «многие-к-многие», но может обрабатывать отношения «много к многим».
Пример 3: В «Библиотечной информационной системе» «книга» — это сущность, а «читатель» — тоже сущность. Эти две сущности — одно и то же
Взаимоотношения между книгами — типичные отношения «много к многим»: книгу могут брать несколько читателей в разное время, и один читатель может брать больше
Эта книга. Для этого следует добавить третью структуру между ними, которая называется «заимствование и возврат книг», свойства которой таковы: время заимствования и заимствование
У него также есть логотип (0 означает одолжение книги, 1 — возврат книги), кроме того, должно быть два внешних ключа (первичный ключ от «книга» и первичный ключ от «читатель»), так что
Она связана с «книгами» и «читателями».
7. Метод значения первичного ключа PK
PK — это инструмент межстольного соединения для программистов, который может представлять собой строку чисел без физической значимости, автоматически добавляемую программой к 1. Да
это физически значимое название поля или сочетание имён полей. Но первый вариант лучше второго. Когда PK — это комбинация имён полей, предложите номер поля
Не считайте слишком много, ведь индекс занимает не только много места, но и замедляется.
8. Правильно определить избыточность данных
Повторение первичных и внешних ключей в нескольких таблицах не является понятием избыточности данных, и многие об этом не знают
。 Повторение неключевых полей — это избыточность данных! И это низкоуровневая избыточность, то есть повторяющаяся избыточность. Расширенная избыточность не основана на полевых условиях
Многократно, но производные полей.
Пример 4: Три поля «цена единицы, количество и сумма» в продукте «сумма» производится из «цены единицы», умноженной на «количество».
Это избыточность, и это своего рода продвинутая избыточность. Цель резервирования — увеличить скорость обработки. Только низкоуровневая избыточность увеличит число
несогласованность данных, поскольку одни и те же данные могут быть введены несколько раз из разных времен, мест и ролей. Поэтому мы выступаем за расширенную избыточность (pie)
избыточность по своей природе), и выступает против низкоуровневой избыточности (повторяющейся избыточности).
9. Стандартного ответа для диаграмм E--R не существует
Не существует стандартного ответа на диаграмму E-R информационной системы, поскольку её дизайн и метод рисования не являются уникальными, при условии, что они охватывают необходимые задачи системы
Масштаб и функциональное содержание вполне реализуемы. Вместо этого необходимо изменить диаграмму E-R. Хотя у него нет единого стандартного ответа, это не означает, что он может быть произвольным
Дизайн. Критерии для хорошей диаграммы E-R: чёткая структура, лаконичная ассоциация, умеренное количество сущностей, разумное распределение атрибутов и отсутствие низкоуровневой избыточности.
10. Методы просмотра полезны в проектировании баз данных
В отличие от базовых таблиц, кодовых и промежуточных таблиц, представления — это виртуальные таблицы, которые зависят от реальных таблиц источника данных. Просмотры предназначены для программистов
Окно с использованием базы данных — это форма синтеза данных базовых таблиц, метод обработки данных и разновидность конфиденциальности пользовательских данных
значит. Для выполнения сложной обработки, увеличения скорости вычислений и экономии места в памяти глубина определения обзора, как правило, не должна превышать три слоя. Около трёх этажей
Если представления всё равно недостаточно, следует определить временную таблицу на представлении, а затем — на временной таблице. Таким образом, глубина обзора определяется многократно
Никаких ограничений.
Для определённых информационных систем, связанных с национальными политическими, экономическими, технологическими, военными и силовыми интересами, роль взглядов становится ещё более важной. Вот эти
После завершения физического проектирования базовой таблицы системы первый слой просмотров сразу устанавливается на базовой таблице, и количество и структура этого просмотра совпадают с базовой таблицей
Количество и структура абсолютно одинаковы. И оговорено, что всем программистам разрешено работать только с видом. Только администратор базы данных с
«Ключ безопасности», удерживаемый несколькими сотрудниками, может управляться непосредственно на базовом столе. Читателям предлагается задуматься: почему так происходит?
11. Промежуточные таблицы, операторы и временные таблицы
Промежуточная таблица — это таблица, которая хранит статистику, предназначена для хранения данных, выводных отчетов или результатов запросов, и иногда у неё нет первичного ключа с
Внешние ключи (за исключением хранилищ данных). Временные таблицы разрабатываются программистами для хранения временных записей для личного пользования. Базовая и промежуточная таблицы поддерживаются DBA
Временные таблицы автоматически поддерживаются самим программистом.
12. Ограничения целостности проявляются в трёх аспектах
Целостность домена: используйте Check для реализации ограничений, а в инструменте проектирования базы данных при определении диапазона значений поля есть Ch
Кнопка ECK, с помощью которой определяется город значений поля.
Референтная целостность: реализовано с помощью триггеров PK, FK и таблицы.
Пользовательская целостность: это некоторые бизнес-правила, реализуемые с помощью хранящихся процедур и триггеров.
13. Метод предотвращения патча в проектировании базы данных — принцип «три меньше»
(1) Чем меньше таблиц в базе данных, тем лучше. Только если уменьшить количество таблиц, можно сказать, что диаграмма E-R системы малая и тонкая, и она убирается
Дублирующиеся и избыточные сущности формируют высокую степень абстракции объективного мира, и систематическая интеграция данных проводится для предотвращения патчного проектирования;
(2) Чем меньше полей в таблице, объединяющих первичные ключи, тем лучше. Из-за роли первичного ключа один из них строит индекс первичного ключа, а другой служит подтаблицей
внешние ключи, поэтому количество полей в комбинации первичных ключей сокращается, что не только экономит время выполнения, но и сохраняет место в индексном хранилище;
(3) Чем меньше полей в таблице, тем лучше. Лишь небольшое количество полей указывает на отсутствие дублирования данных в системе
Избыточность данных минимальна, и, что важнее, читателям рекомендуется учиться «менять строки», что предотвращает попадание полей в основную таблицу подтаблицы
, оставляя множество свободных полей в главной таблице. Так называемая «строка изменения столбца» предназначена для выделения части содержимого основной таблицы и создания отдельной
Подтаблица. Этот метод очень прост, некоторые люди просто не привыкают к нему, не принимают и не реализуют.
Практический принцип проектирования баз данных — найти правильный баланс между избыточностью данных и скоростью обработки. «Три меньше» — это целостный обзор
Мысль, всеобъемлющие взгляды, не могут выделить определённый принцип. Принцип относителен, а не абсолютен. Принцип «ещё трое» определённо неверен. Попробуй
Подумайте: если покрыта та же функция системы, то диаграмма E-R из 100 сущностей (всего 1000 атрибутов) определённо лучше диаграммы E-R, содержащая 200 сущностей (всего 2000 атрибутов)
Диаграмма E-R-R гораздо лучше.
Пропаганда принципа «три меньше» — это возможность читателям научиться использовать технологии проектирования баз данных для систематической интеграции данных. Шаги интеграции данных должны быть выполнены:
Файловая система интегрирована в базу данных приложений, база данных приложений — в тематическую базу данных, а тематическая база данных — в глобальную комплексную базу данных.
Чем выше степень интеграции, тем сильнее обмен данными, и тем меньше информационных островов
Количество первичных ключей и количество атрибутов будет меньше.
Цель продвижения принципа «троих меньше» — предотвратить использование патч-технологий для постоянного добавления, удаления и модификации базы данных с целью создания корпоративных данных
Библиотека превратилась в «мусорную кучу» из произвольно спроектированных таблиц баз данных или «беспорядок» из таблиц базы данных, что в итоге вызывает появление базовых таблиц и генераций в базе данных
Кодовые таблицы, промежуточные и временные таблицы перегружены и бесчисленны, что приводит к невозможности поддерживать и парализовать информационные системы предприятий и учреждений.
Принцип «ещё троих» может применять кто угодно, что является ошибкой метода «патчирования» при проектировании баз данных. Принцип «троих меньше»
Это принцип «меньше, но хорошо», который требует высоких навыков проектирования баз данных и искусства, чего не каждый может сделать, потому что этот принцип устраняется
Теоретическая основа для проектирования базы данных с использованием «метода патчирования».
14. Способы повышения эффективности работы базы данных
В данных аппаратных и программных условиях системы методы повышения эффективности работы системы базы данных следующие:
(1) В физическом проектировании базы данных уменьшить парадигму, увеличить избыточность, использовать меньше триггеров и больше хранящихся процедур.
(2) Когда расчёт очень сложен, а количество записей очень велико (например, 10 миллионов), сложный расчёт должен сначала быть вне базы данных
После того как метод файловой системы вычисляется и обработан на языке C++, он наконец добавляется в таблицу. Это опыт проектирования телекоммуникационных биллинговых систем.
(3) Если в таблице обнаружено слишком много записей, например, более 10 миллионов, таблицу следует разделить по горизонтали. Практика горизонтальной сегментации такова:
Разделите запись таблицы горизонтально на две таблицы на основе определённого значения первичного ключа PK таблицы. Если в таблице оказывается слишком много полей, например, превышение
Восемьдесят — таблица делится вертикально, а исходная таблица — на два стола.
(4) Системная оптимизация системы управления базами данных СУБД, то есть оптимизация различных параметров системы, таких как количество буферов.
(5) При использовании ориентированного на данные SQL языка для программирования старайтесь применять алгоритмы оптимизации.
Короче говоря, для повышения эффективности работы базы данных необходимо оптимизировать систему баз данных, её проектирование и реализацию программы
, эти три уровня одновременно усердно работают.
Вышеуказанные четырнадцать навыков постепенно обобщаются многими людьми в многочисленных практиках анализа баз данных и проектирования. За эти впечатления
Читатели не должны быть жёсткими или шаблонными, а должны усваивать и понимать, искать истину в фактах и гибко осваивать её. И постепенно делайте: отправляйте заявку
Экспозиция, применение в разработке.
|
Опубликовано 09.04.2015 21:00:54
|
|
|
