Database Architecture Design Chapter 2 - Best Practices and Principles | Dan Grijzenhout | Skillshare

Database Architecture Design Chapter 2 - Best Practices and Principles

Dan Grijzenhout, Over 35 years of business experience

Play Speed
  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x
6 Lessons (27m)
    • 1. Chapter 2 Introduction - Database Architecture Design Series

      1:04
    • 2. Database Architecture Design - Best Practices

      11:22
    • 3. Data Transaction Management Services

      3:27
    • 4. Maintaining Data Integrity

      6:08
    • 5. Maintaining Data Security

      3:55
    • 6. Congratulations on Class Completion

      1:09

About This Class

0356c407

Database Architecture Design Chapter 2 - Best Practices and Principles

As corporations increase in size and complexity, securing, managing and insuring the integrity and accuracy of internal data becomes a critical component to continued corporate growth. 

Chapter 2 in my Database Architecture Design series drills down from Chapter 1 where Data Architectural Frameworks were discussed to discuss Data Environment Architectural Principles and Best Practices.  

The chapter begins with a listing of overall architectural principles for an enterprise level data environment (EDE) along with their implications to a corporation if the principle is accepted and adhered to within the corporation.

I follow these overall EDE architectural principles or best practices with further similar lectures covering downstream EDE architectural topics including:

Data Transaction Management Services

Maintaining Data Integrity and

Maintaining Data Security

This class is designed to support the ongoing efforts of an IT department and its data architects and managers in designing, building and maintaining a corporation's business, operational and decision support information systems.  It is an advanced class most useful to database architects, senior information systems analysts and systems development personnel.

Transcripts

1. Chapter 2 Introduction - Database Architecture Design Series: Hello and welcome to Chapter two of my database architecture design class, which I titled Data environment, Best Practices and Architectural Principles. This chapter begins with a listing of overall architectural principles for an enterprise level data environment, or E E, along with their implications to a corporation if the principle is accepted. And here too, I follow these overall e architectural principles or best practices with further similar lectures covering downstream E T e architectural topics, which include data transaction management services, maintaining data integrity and maintaining data security. So if you are a systems and or database professional wanting to increase your depth of knowledge in the information systems architect ING area, this class will improve your understanding of how to architect top down globally distributable database systems. I look forward to seeing you on the inside bye for now. 2. Database Architecture Design - Best Practices: Hello and welcome to my lecture, which I title enterprise, data environment, architectural principles, architectural principles or best practices as they are otherwise called. Our guides to a corporation to be used to ensure consistency of strategy is employed and enforced across separation prior to new development occurring without adherents to best practices such as you will learn about. Within this lecture, a corporation's internal information can become compromised, its value to the corporation, thereby reduced and more effort and cost will have to be absorbed by the corporation to regain trust in its formacion, both internally and to all its stakeholders. Following are a set of standard enterprise level data environment principles or best practices that could be used in your corporation or business once it achieves complexity and sophistication. As you work within your own business environment, discuss these principles provided here in to see us to their applicability, to your organization and to determine implications your corporation would face if the's word here too. Naturally, you will make changes to these as you go along within your company. But these air a good starting point for any business entity and I have worked through the same sorts of best practices with the internal staff at a number of very large corporations , including a few fortune level ones. You will see them listed on my website if you go looking for them. So here they are each best practice or principle that I have selected below has rationale for its existence and also listing of one to several implications that a corporation would have if Internal staff agreed to their inclusion and adherents. Principle one. We will ensure the data definitions air common and standard. We will provide access to and communication off those definitions. Remember, these principles are coming from the enterprise, data environment and architectural staff of that organization. Rationale. A standardized metadata environment will enable i t. To provide more cost effective and timely business solutions to its end users. Now this is gonna have some implications to the corporation, and I've listed a few of these below. First, the customer is accountable for defining the data in business terms, including data descriptions and business rules. I t is then responsible for defining the technical characteristics of the data. I T is further responsible for developing data standards such as naming and formatting standards to promote consistency across the enterprise. I t must provide business entities access to data definitions in a form which is easy to use. A compliance process must be established to ensure that the completeness, accuracy and non redundancy of data definitions occurs. Data definitions must support standard interchange formats. Now ahead on to the second principle Data is owned by I t business entities. It is administered by the business entity appointed data Stewart that's managed by I t. So what kind of ration out would you have for this? Well, data as the basis for information is a valuable corporate asset and is used to provide a competitive advantage. I t owns the structures which store data and the Elektronik processes which transfer and manipulate data. The business entity owes the data that it creates and lastly, the data Stewart administers the data within the enterprise computing environment. This again has implications to the corporation. If this principle is accepted first, I t must define data classifications to support the clear definition of roles and responsibility in relating to this data. I t is responsible for the management of electronic forms of corporate data, including text, digitized voice and image or for that matter, any other type of information stored on the corporation servers. I t customers own the data with the data Stewart administering the data for each subject area database, I t must establish and communicate responsibilities for the following roles. Data owner data Stewart Data Custodian, data Security Administrator, Internal auditor and data user. Now, these names maybe something else in your corporation, but you get the gist here. Principal three globally shared enterprise data will be started managed at the global server level. Remember, we're talking logical global server levels here, not physical deployments. Storing mission, critical data and logical global server levels will simplify the administration of the server environment and improve the control over critical information. And so new applications maintaining network capacity and reliability will be crucial. For success of this principle, I team must know the business entities needs to define shared versus individual into the information. Existing library structures may need to be modified or replaced, and performance standards must be considered principle. Four each business entities data will be secure, recoverable, accessible and independent of another business entities data. So we're talking business units here. If the central site is inaccessible for any reason. Miss Entities can continue to function if they have local access to their own data. This supports the general principle to provide seven day per week 24 hour per day service from I t to the corporation as a whole, ensuring that all business units do have access to their information when they want it. The converse to this is that if the entity site has a repository access problem, they could still have functionality through access to centrally managed applications. Implications I t will need to support and managed to find databases within the frameworks of defined product offerings. Business entity level information will reside in entity cites a definition of what will be shared data and what will be entity. Specific data will need to be understood and defined, and lastly, the management of supported architectures will become more complex. I see a few workshops happening here. Principal five location and structure of data will be transparent to end users, and the rationale for this is that the user does not need to know and should not have to worry about where they're getting the information from this takes and users time that is better spent in managing their business functions, as opposed to worrying about where the source points of their data are now. Implications for this in certain situations of global deployment or multiple business entities accessing common information. Middle where may be required existing library structures may need to be modified. This principle requires that databases are object relational database structures be employed within the corporation. In order to make this work, architectures will need to support this level of end user transparency, and the database may need to be sophisticated enough to manage data fragmentation and off site physical locations. Principle. Six data will be modelled to represent the needs of the business processes. Data, which is model to represent the business, is more flexible and easier to understand. In the past, some data may have been modeled to reflect the needs of the business application which used it. However, this could have made the data difficult to use by other applications and processes because it was so tightly coupled with the original applications usage purpose implications customers need to provide the business expertise necessary to successfully perform data modelling. Business processes need to be very well understood data mining methodologies and tools will most likely be required. Principal seven data structures are designed for a shared data environment. The rationale. The sharing of data among applications minimizes redundancy and enhances data integrity. Share data is also easier to understand and use. If this principles adhere to implications. To ensure that data is shared, it needs to be analysed in model from a corporate aspect. Data is no longer owned by a particular application, but it is instead on by the corporation that creates it in the first place. Additional functions are required to coordinate and manage data sharing. Principal eight data is consistent in definition and content across both operational and decision support databases. Rationale. It is essential that data replicated for decision support purposes has the same definition and content as operational data. If transformation process has changed the definition or content of the data, it becomes difficult to understand and used, and its value to the corporation is thereby reduced. And so the implications here, replication and transformation processes must be designed to protect the integrity of data content and definitions. Replication and transformation processes must be well documented and understood. Principal nine Operational and decision support databases are designed to be independent and the rationale for this there are significant advantages to separating operational and decision support data. Separation of these two types of data improves its availability, response time and accessibility, and lastly, implications. Data warehousing tools and methodologies may need to be researched and implemented. So on this last side, I show you a summary of the data, principles or best practices that we've discussed within this particular lecture series in your own corporation. Go through these and see if the rationale works for you. If the principle itself makes sense to your corporation as a whole and go through each of the implications to see if those aerial implications for your organization and edit them as you feel that you need Teoh good luck in architect ing the data in your company. That's all for this lecture by for now 3. Data Transaction Management Services: Hello and welcome to this lecture, which I titled Best Practices for Data Transaction Management Services. This is a short lecture, but I did not want to lose this concept as part of this lecture. Siri's I only have one item in it to discuss. So here it ISS My principal data Access strategies will utilize prominent open enterprise AP eyes gateways and TP monitors as far as is possible within the givens constraints imposed by the chosen application portfolio. Not my rationale for this principle. These technologies will provide efficient, portable, open access to single or multiple databases resident on various hardware platforms. In addition to this, TP monitors increased the openness of the corporate server applications, and this increases in user performance and high volume environments. Also ensuring data integrity. What are the implications? Well, the database is chosen by the corporation need to be compatible technologically with the above strategy at its core TP monitors may not be required unless high data movement and access volumes require their usage. If used details on any used rolls of TV monitors with within the corporate environment will be stored in the Global Data directory or repository, whatever you've managed to implement within your corporation. So the bottom line here is that his organizations gain in size, complexity and global distribution with increasing amounts of concurrent usage to information requirements that will put pressure on databases to deliver content. It will also be necessary to build in an access tube it to databases using a middleware layer, so as to increase the accessibility of data and information to higher quantities of concurrent users. This capability is most often provided by third party vendors such as B A and others, and now virtual server clusters technologies like VM ware, etcetera and can also be incorporated into the enterprise architecture so as to improve performance and data accessibility toe operational data systems. How these get architected into the environment is something that should be done carefully, as not all of these technological solutions air fully compatible with each other, and some work better with some database systems than with others. The principle above relating to keeping the implementations as open as possible through the use of common and standard AP eyes will go a long way to helping the corporation extend its middleware layers over time and by extension, its concurrent user access capabilities without compromising data integrity and accuracy due to timing delays such as point in time data. Truth to keep this in mind while architect ing the operational data base systems within your corporation, the more you tightly couple accesses to particular applications as opposed to adhering to common and open a P I standards, the more difficult a time you will have continuing to grow your business, providing quality data in a timely manner. Basically, you have to allow for the easy insertion of middleware layers. That's all for this lecture. Bye for now. 4. Maintaining Data Integrity: Hello and welcome to this lecture which I title Maintaining data integrity. Maintaining the integrity of your corporations Data is a concern for most business entities beyond the necessity to accurately report transactional and financial information to customers. If you do not trust the data in your corporation, your internal strategic decision making processes, if based on inaccurate DSS information, could lead your executives in the wrong business decisions with possibly disastrous effect . With this in mind, I have included a lecture on strategies of corporations should consider to ensure that they're doing all the big and to maintain the integrity of internal information and data. These strategies below relate to both actual data and corporations metadata as well, which is often stored in some form of metadata repository and I have another course coming out shortly on the reasons why an organization should build such a repository, along with tips on how to construct one. The lower some strategies to consider to ensure data integrity within your corporation can be maintained. Rationale for the strategies and relating implications of those strategies are implemented in the tables. Following first, we will base our data environments unproven. Rt bms That's relational database management system products that have demonstrated referential integrity, roll back roll forward and hot backup and recovery capabilities. The rationale for this is that the corporation needs to ensure that data used throughout the enterprise is consistent, accurate, reliable and recoverable. What implications relate to this? Well, we'd implemented methodology that ensures full recovery and restore capabilities for all data types, including data, voice and image based on rules defined by the business. Also, this methodology needs to apply to the repository databases well. Next, we will ensure that the already be a mess product we implement will contain referential and distributed server integrity through either product functionality or, if necessary, additional custom development. Next, we would need to endeavour to replicate data strategically minimizing this faras possible duplication and redundancies that can affect the integrity of information and data used by business personnel. Rationale, nonstrategic duplication of data can create situations where the data used by individuals is no longer accurate. For example, based aid in the source system may have changed over time, so reports generated from a copy could be ultimately using inaccurate data or information and an implication to this. An integrated data dictionary and repository would be needed to help minimize nonstrategic data replication. For example, designers and developers would have better access to course systems data details, including data business definitions, where and how it's used and where is its point of truth. So some resulting strategies from these principles and tasks that would need to be undertaken to enable and bring these principles into operation within a corporation would include the following. The company would need to implement a methodology that ensures full recovery and restore capabilities for all data types, including data, voice and image based on rules defined by the business. This methodology needs to apply to the repositories databases, while so in relation to this, the corporation would need to develop a backup restore strategy and management process for the data repository. The company would also need to set up a repository environment to store data management methodologies and processes. Next, it would need to develop, implement and test these backup and restore processes, assigning someone in operations to perform these tasks routinely in alignment with the backup and restore strategy. And once in a while the company would need to monitor this process in operation from a quality assurance perspective. The company would also need to ensure that the database product that it implements would contain referential and distributed server integrity through either product functionality or custom development. This means that it would need to implement the repository on an industry strength database that aligns with that strategy. Next, an integrated data dictionary and repository would be required to help minimize nonstrategic data replication. For example, designers and developers would have better access to course systems data details, including data business definitions, where and how it's used and where its point of truth. ISS And this, by extension also means that the company would need to reverse and forward engineer all core systems. That's applications, data processes, etcetera into any new repository environment that it has created for the purpose. The company would need to build business definitions, ownerships, point of truth and data relationships and groupings, and store all of that into the repository. And it also might mean the hiring and training of additional data analysts into the company to perform all these tasks because it could be extensive. Once the new repository is populated, the company should publish a document promoting the use of the data repository across the enterprise and how to use it, access it and updated as required. The company would need to prepare and provide training for analysts and other key personnel on how to use access and update the new repository along with it. In summary, these principles outline ways a corporation can maintain the integrity of its information and data across the enterprise and lays out some strategies for doing so, including the construction of a global metadata repository, for which I am building an additional course as well. That's all for this lecture. Bye for now. 5. Maintaining Data Security: Hello and welcome to this lecture, which I title. Maintaining data security, data security and concept is about controlling access to data and protecting it. This encompasses viewing data, adding new records, editing existing records and the leading records. In this lecture, I discuss the best practice or principle that can act as a good corporate guideline to assist in protecting the security of the corporations. Internal Data assets. This principle, its rationale in corporate implications, appear following database security will be integrated with and support a single, centrally controlled network security system to provide authentication and access control. Now what this really means and its rationale is as follows. Each business entities data needs to be secure and accessible to authorized users when and where needed. So what does this really mean in terms of implications to the corporation? Well, a data repository should be implemented and managed by a repository. Stewart, who assigns crowd security levels that's create, read, update and delete security levels for roles, specific users and even field levels within the repository itself. For example, private data such as salary information, a corporation's global in enterprise levels of this repository environment should be centrally controlled to ensure continued integrity of the environment and its contents, a repository Stewart needs to define and user groups and related access privileges Stewards need to define training requirements for each end user group required to permit the appropriate levels of access. Repository stewards will need to define and user access privileges and update processes to support global end user requirements. And the repository Stewart needs to define and utilize quality assurance processes to ensure repository integrity continues with respect to the above principles emphasis on maintaining security on a data repository environment, I make the assumption that within the operational and DSS databases and applications themselves that data security is present. This is enforced by log ins, passwords, encryptions, etcetera, which are built into the application environments themselves and into the inherent crowd controls, processing and roll back features built into the databases. One service that applications provide is coating that helps to enforce rules relating to data and creating, changing or deleting it. One thing to remember as an architect is to make use of applications as far as is possible when changing data within its database tables, as the more you directly interface with databases themselves for purposes other than to view the data within it. The more you risk the integrity of this data used in these applications as you're bypassing the rules in Stan Shih ated, that is to say, implemented within the application itself that were put there to protect the application. It's data content and data state. So always be very careful in situations where you want to change the data itself externally to the application. You will not always be certain of the intended use of the table, whose content you are changing and how the application intends to process this data within the table as it performs its systems operational tasks. With this in mind, I would place other related best practices that come to mind in this regard into an application, Architecture, Best Practices and Frameworks lecture series. This is something I do plan to create in the near future, as well as part of my training course in this area. That's all for this lecture by for now 6. Congratulations on Class Completion: Hello and congratulations on completing this class. It's great to see and making it all the way through. And I hope I was able to give you some useful and lasting knowledge that will help you and whatever you're wishing to achieve. If you're liking the content that I'm creating, I'm very much looking forward to seeing you in more of my classes, which you confined in this site by going to my profile section. You can still reach me through this class. If you have questions by starting a discussion with me, I'll be more than happy to respond if I hear from you. A second thought that comes to mind is that if you have appreciated the content I have created, please give me a thumbs up where and when the site ask you to to rate my class. This helps me trend better in the system and helps me to reach more people who could benefit from the training I'm trying to create. And if you choose to share the class link with friends or anyone else, thank you for that additional support for my creations as well. Bye for now,