exam12 2 - stankin/design-part-2 GitHub Wiki

Выполнил: Искоркин Алексей, ИДБ-19-05
Проверил: Иванов Петр, ИДБ-19-05

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

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

Схема базы данных - формальное описание данных в соответствии с конкретной схемой данных.

Схема данных - логическое представление организации данных.

Инкапсуляция — это объединение данных и методов для оперирования этими данными или ограничение прямого доступа к каким-то компонентам объекта. Инкапсуляция используется для того, чтобы прятать значения или состояния структурированных данных внутри класса, запрет неавторизованного прямого доступа к ним.

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

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

Из всего многообразия возможностей ООП, есть одна базовая, которая для большинства программистов ассоциируется с ООП. Она называется инкапсуляция. Инкапсуляция – это объединение функций и данных в рамках одной структуры, внутреннее состояние которой (данные) скрыто от внешнего мира. Назначение инкапсуляции — собрать в одном месте знания, относящиеся к устройству некой сущности, правилам обращения и операциям с ней. Инкапсуляция появилась гораздо раньше, чем принято думать. Модули в программах на C — это инкапсуляция. Подпрограммы на ассемблере — это инкапсуляция.

В большом числе источников под инкапсуляцией понимают сокрытие данных (data hiding) от прямого внешнего обращения (обычно с помощью ключевых слов private, protected). Несмотря на то, что это распространенное определение, стоит разделять объединение данных с методами и сокрытие этих данных. Есть языки, например Python, в которых есть объединение данных, но нет сокрытия данных. Причем если в этих языках ввести сокрытие данных, то архитектура программ не изменится, а вот если разъединить данные и методы, то придется переписать практически весь код. Примерно такая же картина и с языками, в которых есть сокрытие данных. Если его убрать, то мало что поменяется, кроме того, что разработчикам придется быть чуть аккуратнее при работе с объектами.

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

Данная модель ярко иллюстрирует принципы "закрытости", присущие методу инкапсуляции. Говоря о системе, использующей модель "черного ящика" мы можем утверждать, что ее содержимое инкапсулировано. Алгоритмическая реализация полностью скрыта. Также в данном случае исключено внешнее вмешательство.

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

Использование "черного ящика" с точки зрения инкапсулирования может быть поделено на 2 категории:

1. Готовые продукты, конфигурацию которых никак нельзя изменить. Данная категория актуальна для компаний, которые получают прибыль от продажи и поддержки своих модулей и библиотек, например Oracle.

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

Однако в данном случае инкапсуляция порождает ряд проблем:

• Входы и выходы могут быть неоднозначно определены;

• Есть возможность ошибки внутри "черного ящика";

• Вместо упрощения работы, может произойти обратное.

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

Object-relational mapping (ORM) - это способ (он же шаблон проектирования) доступа к реляционной базе данных с помощью объектно-ориентированного языка (например, Java). Существует несколько реализаций ORM почти на каждом языке, например: Hibernate для Java, ActiveRecord для Ruby on Rails, Doctrine для PHP и SQLAlchemy для Python. В Java ORM даже стандартизирован как JPA.

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

Также ORM позволяет разработчикам избежать проблем с несовместимостью и изменениями в схеме базы данных. Если в схеме базы данных произойдут изменения, то ORM автоматически обновит объектную модель, что позволит избежать необходимости ручного изменения SQL-кода. Кроме того, ORM может улучшить производительность приложений, так как он кэширует объекты и минимизирует количество запросов к базе данных.

Одним из недостатков ORM является то, что он может замедлить выполнение некоторых запросов к базе данных, так как он добавляет дополнительный слой абстракции, который может замедлить выполнение запросов. Кроме того, ORM может быть ограничен в функциональности и не поддерживать некоторые возможности, которые предоставляет нативный SQL. Это может ограничить возможности разработчика и сделать некоторые запросы невозможными для выполнения.

В противоположность реляционным БД и ORM фреймворков, где операции над данными (вставка, удаление, модификация), являются общими и могут быть применены к любым объектам (таблицам) БД, объектно-ориентированные БД обеспечивают инкапсуляцию данных, т.е. ограничивают область видимости данных, принадлежащих объекту (и, следовательно, доступ к ним). Доступ к таким данным представляется только операциям этого объекта. В идеале для каждого атрибута объекта должна быть определена операция доступа (get). Но требования полной инкапсуляции приводят к невозможности выполнения параллельных транзакций и быстрого поиска на основе индексов. Инкапсуляция также приводит к тому, что обеспечение целостности становится задачей каждого объекта в отдельности. Лишь ссылочная целостность может контролироваться системой снаружи. Поэтому требования инкапсуляции объектов в ООБД выполняются только на уровне пользователей, а не системы в целом.

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

Эта тема вошла в сравнительный анализ инструментов при выборе типа БД на этапе реализации программного модуля.

1. Понятия базы и структуры данных

2. Понятия черного и белого ящика в моделировании

3. Сущность объектно - ориентированного подхода

4. Хабр

5. ORM

6. Инкапсуляция данных